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Use of SHA-2 Algorithms with RSA in 
DNSKEY and RRSIG Resource Records for DNSSEC 
Abstract 
This document describes how to produce RSA/SHA-256 and RSA/SHA-512 


DNSKEY and RRSIG resource records for use in the Domain Name System 
Security Extensions (RFC 4033, RFC 4034, and RFC 4035). 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the BSD License. 
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1. Introduction 


The Domain Name System (DNS) is the global, hierarchical distributed 
database for Internet Naming. The DNS has been extended to use 
cryptographic keys and digital signatures for the verification of the 
authenticity and integrity of its data. [RFC4033], [RFC4034], and 
[RFC4035] describe these DNS Security Extensions, called DNSSEC. 


RFC 4034 describes how to store DNSKEY and RRSIG resource records, 
and specifies a list of cryptographic algorithms to use. This 
document extends that list with the algorithms RSA/SHA-256 and RSA/ 
SHA-512, and specifies how to store DNSKEY data and how to produce 
RRSIG resource records with these hash algorithms. 


Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family 
of algorithms is assumed in this document. 
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To refer to both SHA-256 and SHA-512, this document will use the name 
SHA-2. This is done to improve readability. When a part of text is 
specific for either SHA-256 or SHA-512, their specific names are 
used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be 
grouped using the name RSA/SHA-2. 


The term "SHA-2" is not officially defined but is usually used to 
refer to the collection of the algorithms SHA-224, SHA-256, SHA-384, 
and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2 
will only refer to SHA-256 and SHA-512 in this document. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


DNSKEY Resource Records 


The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110] 
describes the use of RSA/SHA-1 for DNSSEC signatures. 


1. RSA/SHA-256 DNSKEY Resource Records 


RSA public keys for use with RSA/SHA-256 are stored in DNSKEY 
resource records (RRs) with the algorithm number 8. 


For interoperability, as in [RFC3110], the key size of RSA/SHA-256 
keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 
bits. 


.2. RSA/SHA-512 DNSKEY Resource Records 


RSA public keys for use with RSA/SHA-512 are stored in DNSKEY 
resource records (RRs) with the algorithm number 10. 


The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and 
MUST NOT be more than 4096 bits. 


RRSIG Resource Records 


The value of the signature field in the RRSIG RR follows the RSASSA- 
PKCS1-v1_5 signature scheme and is calculated as follows. The values 
for the RDATA fields that precede the signature data are specified in 
[RFC4034]. 


Jansen Standards Track [Page 3] 


RFC 5702 DNSSEC RSA/SHA-2 October 2009 


hash = SHA-XXX (data) 


Here XXX is either 256 or 512, depending on the algorithm used, as 
specified in FIPS PUB 180-3; "data" is the wire format data of the 
resource record set that is signed, as specified in [RFC4034]. 


signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) 


Here mt is concatenation; "00", "01", "FF", and "00" are fixed 
octets of corresponding hexadecimal value; "e" is the private 
exponent of the signing RSA key; and "n" is the public modulus of the 
Signing key. The FF octet MUST be repeated the exact number of times 
so that the total length of the concatenated term in parentheses 
equals the length of the modulus of the signer’s public key ("n"). 


The "prefix" is intended to make the use of standard cryptographic 
libraries easier. These specifications are taken directly from the 
specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of 
[RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2 
of [RFC3447]). The prefixes for the different algorithms are 
specified below. 

3.1. RSA/SHA-256 RRSIG Resource Records 


RSA/SHA-256 signatures are stored in the DNS using RRSIG resource 
records (RRs) with algorithm number 8. 


The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as 
specified in PKCS #1 v2.1 [RFC3447]: 


hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 
3.2. RSA/SHA-512 RRSIG Resource Records 


RSA/SHA-512 signatures are stored in the DNS using RRSIG resource 
records (RRs) with algorithm number 10. 


The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as 
specified in PKCS #1 v2.1 [RFC3447]: 


hex 30 51 30 Od 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 
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Deployment Considerations 
Key Sizes 


Apart from the restrictions in Section 2, this document will not 
specify what size of keys to use. That is an operational issue and 
depends largely on the environment and intended use. A good starting 
point for more information would be NIST SP 800-57 [NIST800-57]. 


Signature Sizes 


In this family of signing algorithms, the size of signatures is 
related to the size of the key and not to the hashing algorithm used 
in the signing process. Therefore, RRSIG resource records produced 
with RSA/SHA-256 or RSA/SHA-512 will have the same size as those 
produced with RSA/SHA-1, if the keys have the same length. 


Implementation Considerations 
Support for SHA-2 Signatures 
DNSSEC-aware implementations SHOULD be able to support RRSIG and 


DNSKEY resource records created with the RSA/SHA-2 algorithms as 
defined in this document. 


Support for NSEC3 Denial of Existence 


[RFC5155] defines new algorithm identifiers for existing signing 
algorithms, to indicate that zones signed with these algorithm 
identifiers can use NSEC3 as well as NSEC records to provide denial 
of existence. That mechanism was chosen to protect implementations 
predating RFC 5155 from encountering resource records about which 
they could not know. This document does not define such algorithm 
aliases. 


A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate 
negative answers in the form of both NSEC and NSEC3 with hash 
algorithm 1, as defined in [RFC5155]. An authoritative server that 
does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 
with NSEC denial of existence. 
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6. Examples 
6.1. RSA/SHA-256 Key and Signature 
Given a private key with the following values (in Base64): 


Private-key-format: v1.2 

Algorithm: 8 (RSASHA256) 

Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1LHYWHfoGm 
idzC2RnhwCC2 93hCzw+TFR2ngn80VSY5t2Q== 

PublicExponent: AQAB 

PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr 8dxsNwiDGHzZrMKLN+i/ 
HAam+97HxIKVWNDH2ba 9Mf1SA8 xu 9dcHZAQ== 


Primel: 4c8IvVFulAVXGWeFLLFh5vs7 fbdzdC6U82 fduE6KkSWk= 
Prime2: 2zZpBE8ZXVnL740jG4zINID£H+EORt jJJ3RtaYDugvE= 
Exponentl: G2xAPFfKOKGXGANDVNxd1K1c9wOmmJ5 1mGbzKFFNMFk= 
Exponent2: GYxP1Pa7CAwtHm8SAGX5 94qZVofOMhgd6YFCNyeVpKE= 
Coefficient: icQdNRjJ1ZGPmuJm2TladubcO8x7V4y07avhx4 64tx80= 


The DNSKEY record for this key would be: 


example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI 
my 4h99CqT7 jJwY 3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd40s 8P 
kxUdp6p/D1UmObdk= );{id = 9033 (zsk), size = 512b} 


With this key, sign the following RRSet, consisting of 1 A record: 
www.example.net. 3600 IN A 192.0.2.91 


If the inception date is set at 00:00 hours on January 1st, 2000, and 
the expiration date at 00:00 hours on January 1st, 2030, the 
following signature should be created: 


www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 
20000101000000 9033 example.net. kRCOH6u710Q0Gy9qpC9 
lilsLncJcOKFLJU7GhivUOibu4teYp5VE9RncriShZNz85mw1lMgNEa 
CFYK/1PtPiVYP4bwg==) ; {id = 9033} 
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6.2. RSA/SHA-512 Key and Signature 
Given a private key with the following values (in Base64): 


Private-key-format: v1.2 

Algorithm: 10 (RSASHA512) 

Modulus: 0eg1M5b563z0q4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQO3pf 
Q7qmdaeM1Cé6Nf 8DKGOUPGPXe06cP27/WRODtxXquSUytkOOkJDk 
8KX8PtA0+yBWwy 7UnZDyCkynO00Uuk8HPVt ZeMO1pHt1lAGVnc8V 
JXZ1INKdyit 99waaE4s= 

PublicExponent: AQAB 

PrivateExponent: rFSLIPbJ1L1FFgFc33B5DD1ClegO8e81P4fFadODbp56V7sphKa6 
AZQOCX8NYAew6VXFFPAKTw410dHnK5kIYOwxvfFD  jDcUGza88qbj4 
yrDPSJenkeZbI SMUSSqy7AMF zEolkk6éWSn6k3thUVRgS1qDoOV3 


SEIAsrB043XzGrkKIVE= 

Primel: 8mbt su9T19V7tKSHdCIeprLIQXOLzx1SZun5T1in/OjvxXSUtvD7x 
nZJ+LHqaBj1dIgMbCq2U80040VcK3TS9GiOQ== 

Prime2: 3a6gkfs74d0Jb7yL4 j4adAif4fcp7ZrGt 7GSNRVDDY /Mv4TERAK 
MaOTKN30kKE0A7X+Rv2K8 4mhT40LD111Ecw== 

Exponentl: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiBlgvvs7gJM 
MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyN1xC+Q== 

Exponent2: mtezf9dsDvYOK+gz JOLWYeKgq5xWYBEYFGa3BLocMiF40xkz0Z3Jd 
PZSWU/h1F jp5RV7aPP0Vmx+hN jYMPIQ8Y5w== 

Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7U0UfhJIcylggqwY86IE0Q 


/BkODw4SC9zxnsimmdBXW21zd8Lwuk8FQcQ== 
The DNSKEY record for this key would be: 


example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHONTOW+et 8 6KuUJOWRD 
plpndvwb6Y8 3nSVXXyLA3DLroROUkKN6X006pnWn jJQu4jX/AyhqFD 
xj13tOnD9u/1TkTg7cV6rk1MrZDtJCQ5PC1/D7ONPsgVsMulJ208g 
pMpztNFLpPBz1lbWxX jDtaR7ZOB1Z3PFY12ZTSncorffcGmhoL 
); {id = 3740 (zsk), size = 1024b} 


With this key, sign the following RRSet, consisting of 1 A record: 
www.example.net. 3600 IN A 192.0.2.91 


If the inception date is set at 00:00 hours on January 1st, 2000, and 
the expiration date at 00:00 hours on January 1st, 2030, the 
following signature should be created: 


www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 
20000101000000 3740 example.net. tsb4wnjRUDnNB1IBUitt 
6TMTXThIVnNG+eCkWqjvvjhzOL1d0YRoOe0CbxrVDYdO0xDtsuJRa 
eUwlep94PzEWzr0iGYgZBWm/ zpqt+9fOuagYJRfDqfReKBzMweOL 
DiNa8iP5g9vMhpuv60P lvpxXwm9Sa9ZXIbDN11IMBGkOfthPgxdDLw 
=);{id = 3740} 
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IANA Considerations 
This document updates the IANA registry "DNS SECURITY ALGORITHM 
NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The 


following entries are added to the registry: 


Zone Trans. 


Value Description Mnemonic Signing Sec. References 
8 RSA/SHA-256 RSASHA256 Y X RFC 5702 
10 RSA/SHA-512 RSASHA512 Y K RFC 5702 


* There has been no determination of standardization of the use of 
this algorithm with Transaction Security. 


Security Considerations 
1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records 


Users of DNSSEC are encouraged to deploy SHA-2 as soon as software 
implementations allow for it. SHA-2 is widely believed to be more 
resilient to attack than SHA-1, and confidence in SHA-1’s strength is 
being eroded by recently announced attacks. Regardless of whether or 
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the 
time of this writing) that SHA-2 is the better choice for use in 
DNSSEC records. 


SHA-2 is considered sufficiently strong for the immediate future, but 
predictions about future development in cryptography and 
cryptanalysis are beyond the scope of this document. 


The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one 
used for RSA/SHA-1 signatures. This should ease implementation of 
the new hashing algorithms in DNSSEC software. 


-2. Signature Type Downgrade Attacks 


Since each RRSet MUST be signed with each algorithm present in the 
DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a 
malicious party cannot filter out the RSA/SHA-2 RRSIG and force the 
validator to use the RSA/SHA-1 signature if both are present in the 
zone. This should provide resilience against algorithm downgrade 
attacks, if the validator supports RSA/SHA-2. 
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